iT邦幫忙

2021 iThome 鐵人賽

DAY 6
1
Mobile Development

如何用下班時間開發App經營副業系列 第 6

沒想太多就用了 MongoDB 的結果 (中)

  • 分享至 

  • xImage
  •  

初始設定

一開始我們就在 Azure 租一個 node , 程式後端(以下稱API)、Nginx、MongoDB 都在裡面,完全是輕輕鬆鬆的會發生 single point of failure
後來發現這樣,要 deploy 後端程式時候,就要把服務暫停才行。所以就把 API 跟 MongoDB 拆開,然後多加了幾個 API 的 instance。

第一次遇到問題:太會聊天

本來因為 array 很方便,我們本來就開了一個儲存對話的 collection,兩個人間的對話就是一個 document。後來開始有人越用越多後,才發現一個 document 的大小有上限 (16M),居然有人可以聊到達到這個上限。雖然算是 corner case,但也讓我們發現目前的 schema 不可行,於是存對話的部分,改成了一個新的 collection,一個 document 就是一個訊息加上一個對話 ID。

第二次遇到問題:out of memory

後端跟資料庫分開後,資料庫這邊維持現狀好一陣子。
後來用戶又持續增長,效能開始出問題後,就開始研究要怎麼不用花太多錢改善效能。這也是有錢大公司跟沒錢小團隊的最大差別。畢竟現在都是 host 在雲端,只要有錢,按幾個鍵提升主機的規格,效能馬上改善。

雖然透過增加 index 可以改善,但我們遇到一個問題是,尖峰時段 MongoDB 會用超過 VM 的可用 memory (Out of memory) ,此時就會慢到不行,也就只好認明提升 instance 的規格。我們每次都是出事了才提升規格,目前已經改了好幾次。難以想像以前要自己在辦公室放主機的時代要多麻煩,哈哈。

第三次改善

後來看了 Mongo 官方建議。發現推薦的形式是要有至少三個 instance: primary、replica、arbiter。
我們才加到三個 insance。這也讓我們大幅降低跟資料庫有關的 downtime。

光是 mongo 就好多可以寫,哈哈。下次寫最終形態的改善。

最新文章會分享在臉書:https://www.facebook.com/gigi.wuwu/
歡迎留言討論


上一篇
沒想太多就用了 MongoDB 的結果 (上)
下一篇
沒想太多就用了 MongoDB 的結果 (下)
系列文
如何用下班時間開發App經營副業30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言